Distributed computing has evolved from intra-enterprise application integration, where application developers work together to develop and code to agreed upon method interfaces, to inter-enterprise integration, where E-Services may be developed by independent enterprises with completely disjoint computing infrastructures. To accommodate the change, E-Services, which may include services, agents, and web-services, should be able to communicate and exchange business data in a meaningful way, and have some degree of flexibility and autonomy with regard to the interactions.
Several existing agent systems allow services/agents to communicate following conversational protocols. However, all of these agent systems are tightly coupled to specific service/agent systems, and require that all participating entities be built upon a common service/agent platform.
Peer-to-Peer (P2P) technology brings distributed computing capabilities to individuals, creating a new perspective of network-capable devices in the role of resources that can be combined to enable new capabilities greater than the sum of the parts. As services become more loosely coupled and increasingly autonomous, heterogeneous distributed services should be able to discover and converse with each other dynamically, with or without human intervention. Current paradigms of service interaction, however, require service developers to hardcode their logic to adhere strictly to pre-defined conversation policies.
For example, Bradshaw, J. M. provides an open distributed architecture for software agents, e.g., the Knowledgeable Agent-oriented System (KAoS), in the 1996 issue of “Knowledge Acquisition for Knowledge-Based Systems Workshop,” entitled “KAoS: An Open Agent Architecture Supporting Reuse, Interoperability, and Extensibility.” However, as with other conventional techniques, KAoS requires agent developers to hard-wire conversation policies into agents in advance.
Walker, A. and Wooldridge, M. address the issue of how a group of autonomous agents can reach a global agreement on conversation policy in the 1995 issue of “First International Conference on Multi-Agent Systems,” entitled “Understanding The Emergence Of Conventions In Multi-Agent Systems.” However, Walker and Wooldridge require the agents themselves to implement strategies and control.
Chen, Q., Dayal, U., Hsu, M., and Griss, M. provide a framework in which agents can dynamically load conversation policies from one-another in the 2000 issue of “First International Conference on E-Commerce and Web-Technology,” entitled “Dynamic Agents, Workflow and XML for E-Commerce Automation.” But the solution of Chen et al. is homogeneous and requires that agents be built upon a common infrastructure.
A few E-Commerce systems also support conversations between services. However, these systems all require that the client and service developers implement matching conversation control policies.
For example, RosettaNet's Partner Interface Processes (PIPs) specify roles and required interactions between two businesses, while Commerce XML (cXML) is a proposed standard being developed by more than 50 companies for business-to-business electronic commerce. However, both RosettaNet and CommerceOne require that participating services pre-conform to their standards.
To illustrate, in an E-Service marketplace with two different enterprises, a client service in one enterprise may have discovered a storefront service in another enterprise. In order to complete a sale, a credit validation service in yet another enterprise may be employed by the storefront service to make sure that the client is credible. These services can communicate by exchanging messages using common transports and message formats. The storefront service may expect that message exchanges, i.e., the conversation, follow a specific pattern. So does the credit validation service. Because the client and the storefront services belong to different enterprises and have discovered each other dynamically, the client service may not know what conversations the storefront service supports. Similarly, the credit validation service may not know what conversations the client service or the storefront service supports. Accordingly, explicit conversation control implementation may be needed to conduct a conversation between the client service and the storefront service, between the client service and the credit validation service, and between the storefront service and the credit validation service.
Accordingly, current conversation systems require participating service developers to implement logic code to adhere strictly to pre-defined conversation policies. Should a conversation protocol change, all participating services that support the protocol must be updated and recompiled, reducing the likelihood that two services that discover each other will be able to converse spontaneously.
WSCL (Web Services Conversation Language) addresses the problem of how to enable E-Services from different enterprises to engage in flexible and autonomous, yet potentially quite complex, business interactions. It adopts an approach from the domain of software agents, modeling protocols for business interaction as conversation policies, but extends this approach to exploit the fact that E-Service messages are typically XML-based business documents and can thus be mapped to XML document types. Each WSCL specification describes a single type of conversation from the perspective of a single participant. A service can participate in multiple types of conversations. Furthermore, a service can engage in multiple simultaneous instances of a given type of conversation. However, WSCL does not include any means of specifying document transformations.
There are other, similar, business interaction languages, but none of these include document transformations. For instance, the Oracle Integration Server, as described by C. Bussler, “Semantic B2B Integration Server Technology as Infrastructure for Electronic Hubs,” First International Workshop on Electronic Business Hubs. XML, Metadata, Ontologies, and Business Knowledge on the Web (September 2001), includes a semantic transformation engine for transforming documents, but requires the application developers to provide explicit document transformations to an intermediary form specific to the integration server.
Further, the problem of disparate services utilizing different conversation protocols (flow) is exacerbated by similar conversation protocols using documents that vary insignificantly. A mere change in a field name can thwart a program from autonomously managing a conversation between two services. It is therefore desirable to enable automatic transformation of documents during a conversation.